XML Configuration File

The deployment feature is used by identifying a deployment configuration file as explained in the Command Line Usage section. This configuration file is written in XML and is quite simple to use. Here is a basic configuration file to start understanding how to write your own configuration file:

<setup xmlns="http://dtf.org/v1">
   
<dtfc host="${host}" path="dtf/dtfc" user="${user}">
      
<dtfa host="${host}" path="dtf/dtfa1" user="${user}">
         
<property name="node.id" value="1" />
      
</dtfa>
      
<dtfa host="${host}" path="dtf/dtfa2" user="${user}">
         
<property name="node.id" value="2" />
      
</dtfa>
      
<dtfa host="${host}" path="dtf/dtfa3" user="${user}">
         
<property name="node.id" value="3" />
      
</dtfa>
      
<dtfx host="${host}" logs="tests/ut/output/ut_results.xml" path="dtf/dtfx" test="tests/ut/echo.xml" user="${user}">
          
</dtfx>
   
</dtfc>
</setup>

Now from the previous example you can see that the configuration file is very easy to read and you could easily get started writing your own quickly. Just as any other DTF XML file you can use properties that you can easily then specify on the command line and control the deployment setup easily from the command line.

Aside from being able to use the properties you can also specify the exact properties to load into each component at startup. The property loading is done the same way as it would be when you're using the dtf.defaults property but the loading is handled by the deployment feature itself. You can read more on the dtf.defaults feature at Loading Default Properties.

There are a few other important attributes to be specified when identifying the various components that make up your DTF setup. These attributes are all well documented at Deployment Tags.

Another few things to remember when writing these configuration files is that you don't have to identify the DTFX and can instead use this file to simply startup and run your tests against the same setup many times. You can also use the deploy-status to check the status of the setup and easily restart the deployment before running your existing tests against a well known and well defined setup.